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Abstract 

A  major  Department  of  Defense  challenge  continues 
to  he  the  synchronized  interoperability  of  multiple 
command  and  control  and  M&S  programs.  The  Army 
has  three  major  Command  and  Control  (C2)  efforts  to 
contend  with:  ABCS  migration,  FCS  development,  and 
the  Joint  Net  Enabled  Command  and  Control  (NECC) 
program.  These  C2  systems  will  be  operating  in  a 
Service  Oriented  Environment  (SOE)  that  will  be 
implemented/fielded  in  phases  over  time.  There  is  no 
single  process  that  is  aligning  these  efforts  at  a  level 
that  includes  totally  synchronized  technical  exchanges 
of  standards,  data,  and  re-use  of  components.  Two  of 
the  Army's  key  M&S  initiatives  also  have  development 
cycles  that  do  not  parallel  the  C2  schedules  and  do 
not  yet  fully  address  operating  in  a  SOE.  The 
JLCCTC  development  has  to  date  been  on  an  annual 
development  cycle  but  is  currently  moving  to  a  2  year 
cycle.  The  other  big  M&S  initiative,  LVC-IA,  is 
developing  a  prototype  system  with  a  target  date  of 
EY1 0.  Integrating  all  of  these  phased  C2  and  M&S 
programs  will  require  innovative  technical  and 
programmatic  methods. 

1.  Introduction 

A  major  Department  of  Defense  challenge 
continues  to  be  the  synchronized  interoperability  of 
multiple  Command  and  Control  (C2)  and  M&S 
programs  [1][3].  The  Simulation  to  C4I 
Interoperability  (SIMCI)  program  has  been  addressing 
this  problem  successfully  for  many  years  [2]. 
However,  this  problem  is  being  exacerbated  by  the 
unsynchronized  insertion  of  new  technology.  C2 
systems  are  migrating  to  a  Service  Oriented 
Environment  (SOE)  that  will  be  implemented/fielded 
in  phases  over  time.  Also  M&S  systems  will  have  to 
migrate  their  interfaces  in  order  to  effectively  simulate 
and  stimulate  C2  systems.  However,  they  will  have  to 
be  able  to  support  interfaces  to  different  SOE 
implementations  and  also  pre-SOE  implementations  at 


the  same  time.  Integrating  all  of  these  phased  C2  and 
M&S  programs  will  require  innovative  technical  and 
programmatic  methods. 

This  paper  will  address  the  critical  operational 
requirements  that  impact  SOE  implementation.  It  will 
then  describe  current  plans  and  interoperability 
impacts.  Technical  challenges  and  potential  solutions 
are  addressed  in  detail. 

2.  Operational  Requirements 

2.1  A  historical  perspective  on  requirements 
for  M&S  and  C2  systems. 

The  Battle  Command  Training  Program  was  the 
first  organization  to  propose  a  requirement  for 
simulations  to  support  training  for  Command  and 
Control  C2.  The  Battle  Command  Training  Program 
(BCTP),  the  Army’s  capstone  combat  training  center, 
is  located  at  Fort  Leavenworth,  Kansas.  BCTP 
supports  realistic,  stressful  training  for  Army  Service 
Component  Commanders/Army  Forces,  Corps, 
Division,  and  brigade  commanders  and  supports  Army 
components  participating  in  joint  exercises  to  assist  the 
Chief  of  Staff  of  the  Army  in  fulfilling  his  duties  to 
provide  trained  and  ready  units  to  win  decisively  on 
the  modern  battlefield  and  to  conduct  contingency 
operations  worldwide.  BCTP  uses  simulation  centers 
worldwide  to  train  commanders  and  staffs. 

At  Ft.  Leavenworth,  where  much  BCTP  work  is 
done,  the  National  Simulation  Center  (NSC)  was 
created  to  support  BCTP  exercises.  The  NSC  and  the 
Jet  Propulsion  Laboratory  developed  Corps  Battle 
Simulation  (CBS)  to  drive  analog  training  events.  As 
the  Army  Battle  Command  System  (ABCS)  began  to 
be  fielded  to  units,  CBS  became  suboptimal  for  digital 
exercises  and  a  requirement  for  new  simulation, 
Warfighter  Simulation  (WARSIM)  emerged. 

The  WARSIM  operational  requirements 
documents  said  that  WARSIM  is  “Designed  and  built 
using  modern  computer  technology,  modern  software 
engineering  techniques,  and  validated  algorithms  and 
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databases,  it  will  allow  units  worldwide  to  train  using 
their  organizational  equipment.”  The  problem  was  that 
the  requirement  was  written  in  isolation  [4] .  It  did  not 
clearly  define  the  requirement  to  stimulate  the  C2 
system.  C2  system  requirements  suffered  the  same 
characteristic:  the  earlier  operational  requirements  did 
not  clearly  identify  the  need  for  a  simulation  that 
would  connect  to  the  C2  system  to  do  the  following: 

•  Support  wargaming  for  the  military  decision 
making  process 

•  Simulate  subordinate  and  parent  unit 
headquarters  to  drive  training  exercise 

•  Perform  the  digital  bookkeeping  for  after¬ 
action  reviews 

In  2005,  the  TRADOC  Program  Integration 
Office  for  Battle  Command  published  the  Battle 
Command  Information  System  Migration  Plan.  That 
document  was  endorsed  by  the  Army  G-3  and,  at  his 
direction,  was  re-written  into  an  Initial  Capabilities 
Document.  The  latter  contained  a  section  on  training 
that  was  prefaced  with  the  following  the  statement: 
“In  order  to  achieve  acceptable  digitally-enhanced 
training  environments,  the  Command,  Control, 
Communications  and  Computer,  Intelligence, 
Surveillance,  and  Reconnaissance  (C4ISR)  systems 
must  be  seamlessly  integrated  and  able  to  interoperate 
with  simulations,  simulators,  and  instrumentation 
systems  to  support  the  time-phased  modernization  to  a 
Modular  Force  structure.” 

This  had  the  effect  of  expanding  the  role  of 
simulations.  It  said  that  all  C2  systems  had  to  be 
“seamlessly  interoperable”  with  the  C2  systems.  The 
scope  was  not  just  focused  on  the  brigade  combat 
team,  divisions  and  corps.  It  now  transgressed  the 
spectrum  of  echelons  from  platoon  to  the  joint  task 
force. 

2.2  The  training  challenge  of  the  Live-Virtual- 
Constructive  (LVC)  training  environments. 

2.2.1  Training,  exercises,  and  military  operations 
(TEMO)  domain 

Training  simulations  belong  to  a  “domain”  of 
models  and  simulations  called  “TEMO.” 

One  of  the  three  domains  for  Army  M&S 
applications,  the  TEMO  domain  includes  most  forms 
of  training  at  echelons  from  individual  simulation 
trainers  through  collective,  combined  arms,  joint, 
and/or  combined  exercises.  The  TEMO  includes 
mission  rehearsals  and  evaluations  of  all  phases  of  war 
plans. 


Within  training  simulations,  there  are  three 
categories: 

•  Live  simulations.  Characterized  by  a  “live” 
situation  where  the  opposing  force  is  real  and 
the  organization  being  trained  uses  their 
organic  equipment.  Real  bullets  are  replaced 
with  laser  inserts  on  the  guns  and  rifles.  The 
C2  suite  associated  with  the  players  is  the 
“real  thing.”  Instrumentation  of  the  range 
provides  the  scoring  and  assessment  of  how 
effective  the  unit  was.  Live  simulations  are 
highly  effective  for  training  formations  up  to 
the  Brigade  Combat  Team  (BCT)  echelon. 

•  Virtual  simulations.  Characterized  by  a 
simulator  that  is  a  mock-up  of  a  piece  of 
equipment.  An  example  of  a  virtual  simulator 
is  a  helicopter  simulation  that  has  all  the 
fidelity  of  a  real  attack  helicopter.  Virtual 
simulations  are  highly  effective  for  training 
individual  Soldiers  or  a  crew  of  Soldiers  on  a 
particular  piece  of  equipment,  e.g.  a  tank. 
Selected  virtual  simulators  can  also  be 
networked  to  create  a  virtual  battlefield  to 
train  combat  tasks  at  the  platoon,  company, 
and  battalion  level. 

•  Constructive  simulations.  Constructive 
simulations  are  more  abstract.  They  use  the 
organization’s  real  battle  command  system 
including  the  communications;  however,  the 
simulation  creates  a  virtual  reality  for  the 
organization  being  trained.  A  battle  captain 
and  other  staff  members  being  trained  at  the 
brigade  echelon  are  presented  with 
subordinate  and  parent  headquarters  as  well 
as  an  opposing  force.  The  simulation  can  run 
in  real  time  as  well  as  slower  or  in  “fast- 
forward.”  While  a  constructive  simulation 
such  as  OneSAF,  can  be  run  at  the  lowest 
echelons,  constructive  simulations  are  most 
effective  in  situations  where  it  is  impractical 
to  field  all  the  organizations’  command  posts 
and  TOCs.  Constructive  simulations  also 
serve  another  purpose,  no  less  important  than 
training.  Constructive  simulations  can  be 


used  for  wargaming  courses  of  action  in  the 
military  decision  making  process. 

2.2.2  Advanced  concepts  and  requirements  (ACR) 
domain 

The  second  of  the  three  domains  for  Army  M&S 
applications,  ACR  includes  experiments  with  new 
concepts  and  advanced  technologies  to  develop 
requirements  in  doctrine,  training,  leader  development, 
organizations,  materiel  and  soldiers  that  will  better 
prepare  the  Army  for  future  operations.  ACR  evaluates 
the  impact  of  horizontal  technology  integration 
through  simulation  and  experimentation  using  real 
soldiers  in  real  units. 

The  ACR  domain  exists  in  organizations  such  as 
the  TRADOC  battle  laboratories  and  TRADOC 
Analysis  Command  (TRAC).  TRAC  has  developed 
the  Advanced  Warfighting  Simulation  (AWARS) 
which  is  used  for  TRAC’s  analyses  of  alternatives. 
The  Battle  Command  Battle  Laboratory  is  one  of 
TRAC’s  customers  for  AWARS.  The  Battle  Lab  uses 
AWARS  for  experiments  such  as  the  Division 
Warfighting  Experiment. 

2.2.3  Research,  Development,  and  Acquisition 
(RDA)  domain 

RDA  is  the  final  of  the  three  domains  for  Army 
M&S  applications.  The  RDA  domain  includes  all 
models  and  simulations  used  for  design,  development, 
and  acquisition  of  weapons  systems  and  equipment. 
Models  and  simulations  in  the  RDA  domain  are  used 
for  scientific  inquiry  to  discover  or  revise  facts  and 
theories  of  phenomena,  followed  by  transformation  of 
these  discoveries  into  physical  representations.  RDA 
also  includes  test  and  evaluation  (T&E)  where  models 
and  simulations  are  used  to  augment  and  possibly 
reduce  the  scope  of  real  world  T&E. 

An  example  of  a  simulation  in  the  RDA  domain  is 
a  model  used  to  represent  live  fire  against  soldiers  and 
their  equipment.  RDA  also  includes  models  for 
financial  and  cost  analyses.  These  are  all 
considerations  in  acquiring  the  capabilities  we  need. 
The  next  section  looks  at  the  process  for  putting 
systems  in  the  hands  of  the  customers. 

2.3  Documenting  an  Integrated  Approach: 

How  to  get  from  a  capabilities  document  to  a 
composite  of  C2  systems  and  simulations  that 


interoperate  “seamlessly.”  The  DoD  has  directed  a 
capabilities-driven  approach  for  improving  the  systems 
to  be  used  by  the  Combatant  Commands. 
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Figure  1.  Capability  Documenting 


Figure  1  shows  DoD’s  process  for  documenting  a 
new  capability.  “Capability”  needs  a  definition  as 
well: 


“Capability”  ...defined 


Figure  2.  Capability  Definition 


Figure  2  shows  the  official  definition  of 
“Capability”.  Note  that  the  capability  is  not  just  a 
materiel  requirement;  it  emphasizes  all  of  the  Doctrine, 
Organization,  Training,  Logistics,  Materiel,  Personnel 
and  Facilities  (DOTLMPF)  functional  areas.  The 
challenge  for  the  Army  becomes  one  of  getting 
multiple  agencies  to  first,  arrive  at  a  common 
understanding  of  what  the  customer  (Combatant 
Commander)  needs  and  how  to  build  and  integrate  the 
individual  pieces  of  a  very  complex  system. 

In  terms  of  C2  systems  and  M&S  materiel,  the 
Army  must  tap  at  least  two  Program  Executive  Offices 
(PEOs):  Command,  Control  and  Communications- 


Tactical  (C3T)  and  Simulation,  Training,  and  Range 
Instrumentation  (STRI)  and  their  Program  Managers 
(PM).  The  capability  that  ultimately  goes  from  the 
TRADOC  proponent  to  the  PMs  has  to  be  universally 
understood.  Accompanying  the  situation  is  getting 
funds  for  the  variety  of  systems  including  dollars  to  do 
the  integration  work  so  that  customer’s  expectations 
are  met.  This  means  that  the  “Pentagon”  must 
understand  the  objective  capability  and  what  the  effect 
of  not  funding  components  is. 

The  capabilities  document  that  originates  in 
TRADOC  has  allied  documents  as  well  that  help  to 
amplify  the  need.  These  include  the  Simulation 
Support  Plan;  the  System  Training  Plan  and  the 
MANPRINT  Management  Plan.  These  three 
documents  are  inter-related  although  they  can  stand 
alone.  The  MANPRINT  Management  Plan  explains 
who  the  users  of  the  systems  will  be;  the  System 
Training  Plan  says  how  the  Army  plans  to  train 
Soldiers  and  units  to  use  the  system;  finally,  the 
Simulation  Support  Plan  provides  a  guide  on  how 
simulations  should  be  used  throughout  the  materiel 
acquisition,  testing,  training  and  ultimately  as 
components  of  the  Battle  Command  System. 

The  last  point  is  critical  and  summarizes  the  stated 
requirement  for  M&S  and  Battle  Command.  The 
Battle  Command  Information  System’s  Migration  Plan 
describes  the  requirement  as  follows: 

“Embedded  Modeling  and  Simulations  for 
Operations  and  Training:  Current  appended  and 
umbilical  systems  cause  interoperability  problems.  Use 
embedded  simulation  applications  and  infrastructure 
components  to  improve  the  Military  Decision  Making 
Process  (MDMP).  This  will  enhance  the  operational 
lethality  of  BC  systems.  Simulation  components  that 
will  enhanced  the  MDMP  and  Course  of  Action 
(COA)  development  and  war  gaming  are  execution 
monitoring,  mission  rehearsal,  After  Action  Review 
(AAR)  support,  archival  training  files,  etc.  In  BC 
systems  using  common  components,  simulation 
functions  such  as  robust  3D  terrain/environmental 
representation  should  co-exist  with  BC  applications  so 
that  the  simulation  can  be  used  for  “what-if?” 
situations.  These  must  be  displayed  as  a  special 
situation  on  the  common  operating  picture  (COP). 
Embedded  modeling  and  simulation  components  add 
automated  features  such  as  estimating  fuel 
consumption,  doing  terrain  mobility  analysis, 
communication  network  analysis,  etc.  These  features 
add  to  the  war  gaming  capability.  While  it  is  possible 
to  embed  an  entire  simulation  application,  it  is  better 
to  construct  a  shared  BC  and  simulation  component 
architecture.  Common  data,  components  and  standards 


shared  among  simulations  and  BC  applications  is  the 
key  to  achieving  this.” 

2.4  Painting  the  Moving  Train 

The  reason  why  there  is  a  Battle  Command 
Migration  Plan  is  because  there  are  C2  and  M&S 
systems  already  fielded.  We  don’t  have  luxury  of 
stopping  the  train  to  put  a  new  coat  of  paint  on  it;  it 
has  to  be  done  in  units  that  already  have  C2  systems 
and  are  presently  engaged  in  combat  operation. 

The  Army  Force  Generation  process  is  a  recent 
technique  to  meet  the  needs  of  the  forces  in  harm’s 
way.  Units  go  through  a  period  of  stand-down  during 
which  their  equipment  is  up-graded  and  the  Soldiers 
are  trained  on  new  tasks.  Subsequently,  the  unit 
completes  a  training  certification  event  at  a  Combat 
Training  Center  and  becomes  ready  for  deployment. 
The  third  and  final  phase  is  the  move  to  the  area  of 
hostility. 

The  PMs  have  the  responsibility  of  ensuring  that 
all  the  systems  are  integrated  so  that  they  can  conduct 
operations  as  a  part  of  the  Joint  Land  Component 
Command  (which  typically  has  Marine  Corps  units  and 
coalition  partners).  This  is  even  more  challenging 
because  commanders  in  the  field  have  chosen  to  build 
their  own  C2  systems.  While  the  “home-grown” 
systems  met  individual  commander’s  needs  very  well, 
planned  interoperability  is  usually  devastated. 

3.  C2  Transition  Plans  and 
Interoperability  Impacts 

The  requirements  identified  and  discussed  in  the 
previous  section  shape  the  acquisition  process  for  our 
current  and  future  warfighting  systems.  Experience 
shows  that  the  current  acquisition  process  is  deficient 
in  allowing  the  flexibility  to  fully  support  integrated 
development,  test,  and  fielding  in  a  system  of  systems 
architecture.  This  inhibits  interoperability  and 
increases  the  risks  and  challenges  as  we  plan  to 
migrate  and  transition  to  a  net-centric  environment. 
These  architectural  problems  are  readily  apparent 
between  C2  systems  but  are  even  further  amplified 
when  we  attempt  to  integrate  and  interoperate  with 
M&S  systems. 

This  section  of  the  paper  will  provide  a  brief 
overview  of  the  current  suite  of  Army  Battle 
Command  Systems  (ABCS)  and  the  future,  emerging 
systems,  the  Future  Combat  System  (FCS)  and  the  Net 
Enabled  Command  Capability  (NECC).  We  will  also 


3.2  Future  Combat  Systems  (FCS) 


look  at  current  M&S  systems  and  how  they  are  being 
used.  Following  these  overviews  a  description  of  the 
transition  plans  will  be  discussed  and  the  impacts  that 
these  plans  may  have  on  interoperability  requirements. 


3.1  Army  Battle  Command  System  (ABCS) 

The  Army  Battle  Command  System  is  a  family  of 
systems  that  provide  the  automation  for  the  battlefield 
functional  areas  (BFAs)  necessary  to  accomplish 


Figure  3.  Army  Battle  Command  System 


warfighting  missions  across  the  spectrum  of 
operations.  There  are  ten  systems  defined  in  the 
current  ABCS  architecture.  Figure  3  [Battle  Command 
Migration  Plan,  PM  Battle  Command  briefing,  12 
April  2007]  shows  a  high  level  view  of  these  services 
as  they  are  hosted  on  a  Battle  Command  Common 
Services  (BCCS)  set  of  computers.  These  systems  are 
primarily  interconnected  through  a  messaging  protocol 
and  routing  service  called  the  Publish  and  Subscribe 
Service  (PASS),  although  there  are  a  number  of  point 
to  point  specific  interfaces  still  implemented.  The 
current  suite  of  ABCS  serves  information  needs  from 
echelon  Theater  down  to  Platoon  and  Squad  level 
command  and  control  needs. 


Figure  4.  Future  Combat  System 

The  Future  Combat  System  (FCS)  is  the  Army's 
modernization  program  consisting  of  a  family  of 
manned  and  unmanned  systems,  connected  by  a 
common  network,  which  enables  the  modular  force, 
providing  our  Soldiers  and  leaders  with  leading-edge 
technologies  and  capabilities  allowing  them  to 
dominate  in  complex  environments  [5].  Figure  4  is  a 
highly  abstracted  view  of  the  FCS  functional 
component  system  types  and  their  linkage  to  a  set  of 
network  services  and  applications  based  on  a 
foundation  of  standards.  The  FCS  is  a  joint  (across  all 
the  military  services),  networked  (connected  via 
advanced  communications)  systems  of  systems  made 
up  of  initially  18  individual  systems  plus  the  network 
and  Soldier  (often  referred  to  as  18  plus  one  plus  one). 
The  FCS  will  enable  the  future  modular  force, 
providing  our  Soldiers  and  leaders  with  leading-edge 
technologies  and  capabilities  allowing  them  to 
dominate  in  complex  environments.  The  FCS  is 
focused  at  provide  these  capabilities  at  the  echelons 
Brigade  and  below.  The  FCS  schedule  has  been 
flexible  based  on  funding  priorities  year  to  year.  The 
fielding  strategy  to  is  provide  early  development 
successes  to  integrate  with  the  ABCS  systems  as  ‘spin¬ 
off’  technologies  until  the  FCS  can  be  fielded  as  a  fully 
functional  capability. 

3.3  Joint  Land  Component  Constructive 
Training  Capability  (JLCCTC) 

The  JLCCTC  is  a  collection  of  integrated 
Simulation  Models  that  stimulate  Army  Battle 
Command  Systems  (ABCS)  to  facilitate  Command  and 
Staff  training.  The  JLCCTC  is  a  federation  of  current 
and  developing  systems  including  Warfighters' 
Simulation  (WARSIM),  One  Semi- Automated  Forces 


(OneSAF),  Corps  Battle  Simulation  (CBS),  and 
Tactical  Simulation  (TACSIM)  [6].  The  JLCCTC 
provides  the  Army’s  primary  set  of  simulation  based 
training  tools. 

3.4  BC  Migration  Plan 

A  Battle  Command  Migration  Plan  has  been 
developed  and  approved  to  provide  a  campaign  plan 
for  the  transformation  and  development  of  Battle 
Command  (BC)  information  system  capabilities.  The 
document  provides  guidance  and  direction  on  the 
vision,  governance,  and  development  of  Battle 
Command  information  system  capabilities.  [Battle 
Command  Information  System  Integration  & 
Migration  Plan,  Version  1.7.2,  21  November  2005] 
The  BC  Migration  Plan  primarily  focuses  on  the 
transition  of  the  current  ABCS  systems  as  they  evolve 
to  support  warfighter  needs  until  the  FCS  and 
emerging  NECC  systems  become  available  and 
fielded.  The  end  state  vision  of  transition  is  for  the 
capabilities  in  the  ABCS  systems  to  be  assumed  by 
FCS  and  NECC  with  FCS  serving  echelons  Brigade 
and  below  and  NECC  serving  echelons  Brigade  and 
above. 

3.5  Army  Battle  Command  System  Plan 

The  primary  objectives  of  ABCS  migration  to  its 
future  architecture  is  a  consolidation  of  services  onto  a 
Battle  Command  Common  Services  platform  and  the 
migration  from  the  PASS  to  the  Data  Dissemination 
Service  (DDS).  The  DDS  ensures  that  data  is  visible, 
available,  and  usable  when  and  where  it  is  needed  to 
accelerate  decision-making.  Part  of  the  DDS  is  to  also 
ensure  tagging  all  data  with  metadata  to  enable  users  to 
discover  the  data.  These  characteristics  enable  the 
transition  from  a  point-to-point  communications 
architecture  to  a  many-to-many  architecture  that  aligns 
with  the  goals  of  net-centricity. 

3.6  Net  Enabled  Command  Capability 
(NECC)  Plan 

NECC  will  be  the  DoD’s  principal  command  and 
control  information  technology.  NECC  will  enable 
decision  superiority  via  advanced  collaborative 
information  sharing  achieved  through  vertical  and 
horizontal  interoperability.  NECC  will  support  force- 
level  planning,  execution,  monitoring,  and  assessment 
of  joint  and  multinational  operations.  NECC  will  use 
Net-Centric  Enterprise  Services  (NCES)  core 
enterprise  services  and  will  be  able  to  exchange 


information  across  multiple  security  domains.  NECC 
draws  from  the  C2  community  to  evolve  current  and 
provide  new  C2  capabilities  into  a  fully  integrated, 
interoperable,  collaborative  Joint  solution  [7].  NECC 
is  evolving  now  through  a  technology  demonstration 
phase  that  is  seeking  to  harvest  capabilities  from 
different  service  systems  into  a  loosely  coupled,  easily 
accessible  enterprise  structure. 

There  are  many  challenges,  both  programmatic 
and  technical,  that  need  to  be  addressed  to  achieve 
success  in  this  migration.  As  mentioned  previously 
these  challenges  are  both  technical  and  programmatic. 
The  ABCS  systems  need  to  continue  to  evolve  to 
support  the  warfighter  until  the  FCS  and  NECC 
programs  can  be  fielded.  As  ABCS  evolves  it  needs  to 
accommodate  the  technology  insertions  coming  from 
the  FCS  program  while  maintaining  its  focus  on 
emerging  needs  from  the  field.  The  Army  is  at  war 
which  has  draining  effects  on  many  resources.  The 
FCS  and  NECC  are  inherently  Joint  systems  which 
imply  the  need  to  synchronize  with  systems  from  the 
Joint  service  community  as  well  as  meeting  Army 
requirements.  In  addition,  the  M&S  systems  that 
support  the  capability  development,  research,  testing 
and  training  of  all  of  these  systems  has  to  be 
synchronized  and  resources  as  well. 

3.7  Modeling  and  Simulation  Systems  Plan 

M&S  systems  are  currently  developed  and 
managed  in  categories  defined  as  domains.  The  current 
M&S  domains  are  Training,  Exercises,  and  Military 
Operations  (TEMO),  Research,  Development,  and 
Acquisition  (RDA),  and  Advanced  Concepts  and 
Requirements  (ACR).  The  TEMO  domain  primarily 
supports  training,  the  RDA  domain  primarily  supports 
the  research  and  early  prototype  development  and  also 
includes  the  testing  community,  and  the  ACR  domain 
primarily  supports  concept  development  and 
evaluation  to  include  experimentation.  The 
management  of  Army  M&S  is  directed  by  Army 
Regulation  5-11,  “Management  of  Army  Models  and 
Simulations’.  A  new  release  of  this  document  is 
forthcoming  that  has  been  revised  to  update  policy 
with  regard  to  new  management  processes,  the 
establishment  of  integrating  communities  and  other 
communities  of  interest;  and  changes  pertaining  to 
standards  and  the  discontinued  used  of  models  and 
simulations.  These  updates  will  align  the  Army 
management  of  M&S  with  the  recently  created  M&S 
Coordinating  Office  at  the  DoD  level.  The  Army 
Modeling  and  Simulation  Management  Program 
(AMSMP)  will  facilitate  Army  compliance  with  DoD 
policy  and  guidance  for  net-centric  operations  and  the 


net-centric  network.  In  this  sense  this  program  will 
provide  the  transition  guideline  for  Army  M&S  to  the 
net  centric  environment. 

3.8  Live,  Virtual,  Constructive  (LVC) 

Integrating  Architecture  Plan 

The  LVC-IA  will  provide  the  foundational 
structure  and  framework  for  integrating  LVC  systems 
into  the  Integrated  Warfighter’s  Training  Environment 
(the  LVC  Training  Environment) (Figure  5).  The 
objective  of  LVC-IA  is  to  enable  on-demand  training, 
mission  planning  and  rehearsals,  C4ISR  interaction, 
and  Joint,  Interagency,  Intergovernmental  and 
Multinational  (JIIM)  interoperability  anytime  and 
anywhere.  The  LVC-IA  is  a  set  of  protocols, 
specifications,  standards,  and  services/infrastructure 
that  support  the  operation  of  a  seamless  and  integrated 
LVC  environment  where  hardware,  software,  network 
components,  and  modules  are  interoperable  with  other 
LVC  components  and  the  Battle  Command  systems 
[8]. 


Figure  5.  LVC-IA 


The  LVC-IA  will  allow  the  transition  away  from 
the  narrowly  defined  domains  as  previously  described 
for  Army  M&S  and  facilitate  emerging  technologies  to 
provide  advanced  M&S  capabilities.  LVC-IA  also 
explicitly  identifies  the  need  for  interoperable 
interactions  with  live  C4ISR  systems  which  has  often 
been  an  overlooked  in  early  development  and  has 
spawned  a  variety  of  interface  approaches  that  are 
inconsistent,  lack  standardization,  and  are  costly  to 
maintain. 


4.  Technical  Challenges 

In  2000  the  Simulation  to  C4I  Interoperability 
(SIMCI)  Overarching  Integrated  Product  Team  (OIPT) 
described  their  vision  of  an  interoperable  M&S  and 
C4ISR  framework.  The  SIMCI  vision,  referred  to  as 
the  house  chart,  is  based  on  a  common  conceptual 
reference  model  accommodating  common  C4ISR 
component  interfaces,  common  standards  and  tools, 
and  aligned  architectures,  all  linked  via  a  common 
information  management  process  to  provide  common, 
shared  solutions  for  the  C4ISR  and  simulation 
communities.  This  paper  will  use  the  separate 
components  of  the  house  chart  as  depicted  in  figure  6 
to  address  some  of  the  technical  challenges  the  Army 
will  need  to  solve  as  it  transitions  its  battle  command 
and  M&S  systems  from  their  current  to  future  state. 
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Figure  6.  SIMCI  House  Chart 

4.1  Processes  for  Alignment  &  Migration 

A  major  challenge  continues  to  be  the 
synchronization  of  multiple  command  and  control  and 
M&S  programs.  As  depicted  in  figure  6  processes 
work  in  parallel  to  the  other  components  of  the  house 
chart  to  facilitate  the  coordination  of  common 
standards  and  tools,  common  data  models, 
architectures,  and  co-use  of  applications  and  services. 
As  we  look  at  the  Army’s  three  major  axis’s:  ABCS 
migration,  M&S  migration  and  FCS,  and  DISA’s 
NECC  program  it  is  difficult  to  identify  a  single 
process  that  is  synchronizing  these  efforts  at  a  level 
that  encourages  technical  exchanges  of  standards,  data, 
and  re-use  of  components.  ABCS  is  driven  by  the 
Software  Blocking  Program  which  endeavors  to 
manage  the  operational,  systems,  and  technical 
architectures  of  all  iterations  of  ABCS,  aviation,  and 


intelligence  systems  the  Army  develops.  In  cases  of 
standards  such  as  military  message  versions  this  is 
effective  however  since  these  plans  are  developed 
several  years  prior  to  block  execution  they  do  not 
reach  down  to  the  application  or  service  level. 

Additionally  only  systems  designated  for  a  specific 
block  are  required  to  abide  by  the  technical 

architecture  for  that  block  and  there  are  numerous 
weapon  platforms,  M&S,  and  emerging  systems  that 
are  not  included.  Two  of  the  Army’s  key  M&S 
initiatives  have  development  cycles  that  do  not  parallel 
Software  Blocking  schedules.  JLCCTC  development, 
co-managed  by  the  Army’s  National  Simulation  Center 
and  PEO  STRI,  has  to  date  been  on  an  annual 
development  cycle  but  is  currently  moving  to  a  2  year 
cycle.  SWB  cycles  tend  to  be  1.5  years  but  can 

fluctuate  based  on  unit  rotations  and  technical 

challenges.  The  other  big  M&S  initiative,  LVC-IA,  is 
developing  a  prototype  system  at  Fort  Bliss  with  a 
target  date  of  FY10  and  acknowledges  its  development 
will  be  impacted  by  a  number  of  different  programs. 
How  it  will  manage  these  external  impacts  is  unclear. 
FCS  has  a  separate  development  plan  managed  by  the 
ESI.  They  have  implemented  “spin-outs”  to  develop 
interoperability  with  other  Army  systems  as  part  of 
that  plan.  Coordinating  the  dates  of  the  spin  outs  with 
ABCS  and  M&S  development  cycles  will  be 
challenging,  especially  since  FCS  is  the  big  gorilla  in 
the  room  and  has  its  own  milestones  to  meet.  Fastly 
DISA’s  NECC  is  developing  capability  modules  that 
will  be  developed  over  three  increments  with  the  first 
increment  complete  by  FY10.  ABCS  is  the  primary 
Army  system  that  will  interface  with  NECC  but  parts 
of  the  M&S  community  and  eventually  FCS  will  also 
need  this  capability.  Each  of  the  separate  programs 
(ABCS,  M&S,  FCS,  and  NECC)  have  complex 
internal  synchronization  plans  however  what  doesn’t 
exist  is  a  process  to  synchronize  across  all  four 
programs.  This  is  not  say  there  is  no  technical 
exchange  occurring,  the  FCS  and  M&S  community 
(OneSAF  program)  have  a  close  relationship  since 
OneSAF  is  designated  as  the  embedded  M&S  driver 
for  FCS.  In  fact  some  of  the  OneSAF  applications  are 
incorporated  into  FCS’s  System  of  Systems  Common 
Operating  Environment  (SOSCOE)  which  should 
facilitate  FCS  to  JFCCTC  interoperability  when  the 
time  comes. 

4.2  Alignment  of  Architectures 

The  Army  battle  command  community  is  in  the 
process  of  migrating  from  a  message  based,  client 
server  architecture  to  a  Service  Oriented  Architecture 
(SOA)(Figure  7).  ABCS  will  undergo  a  significant 


change  in  architecture  in  software  block  2+  (FY08/09) 
as  it  implements  Data  Dissemination  Services  (DDS) 
and  FBCB2  Joint  Capabilities  Release  (JCR).  In  fact 
ABCS  has  been  progressively  moving  from  military 
standard  messages  (JVMF/USMTF/FDF/TADF)  to 
use  of  publish  and  subscribe  and  Microsoft  exchange 
for  data  dissemination  for  the  past  several  years. 
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Figure  7.  PM  BC  Tech  Vision 

An  often  forgotten  component  of  battle  command 
and  its  architecture  is  the  supporting  communications 
backbone  which  is  the  Army’s  FandWarNet  (FWN) 
which  is  also  undergoing  a  complete  modernization 
from  line  of  sight  radios  to  greater  dependence  on 
satellite  based  systems.  This  also  has  a  significant 
affect  on  battle  command’s  architectures.  M&S,  on  the 
other  hand,  stimulates  battle  command  solely  through 
use  of  military  messages  and  has  no  set  plans  to 
incorporate  DDS  or  even  a  SOA.  In  time  M&S  will 
not  be  able  to  properly  stimulate  Army  battle 
command  systems  because  the  flow  of  information 
(format  and  inject  points)  is  critical  to  the  proper 
distribution  of  information  within  and  across  Tactical 
Operation  Centers  (TOCs).  The  Army’s  training 
philosophy  is  “train  as  you  would  fight”  and 
reconfiguring  battle  command  systems  to 
accommodate  inaccurate  stimulation  by  M&S  would 
be  negative  training.  Clearly  the  M&S  community 
requires  some  forcing  function  be  put  in  place  for  it  to 
change.  FCS’s  architecture  is  essentially  a  microcosm 
of  the  whole  Army  including  the  functional  areas  of 
battle  command,  logistics,  intelligence,  fires,  and 
embedded  training,.  Managing  these  functional  areas 
to  include  their  internal  and  external  interfaces  is  the 
FCS  SOSCOE.  Interoperability  of  ABCS,  M&S,  and 
FCS  will  require  that  current  Army  systems  across  the 
functional  areas  have  two  way  interoperability  with  the 
FCS  SOSCOE.  A  major  challenge  will  be 
development  of  OAs,  SAs,  and  TAs  that  describe  the 
needed  relationships  of  the  three  major  programs. 


4.3  Common  Data 

The  close  coupling  of  battle  command  systems 
among  themselves  (ABCS  and  FCS)  and  with  M&S 
systems  has  emphasized  the  need  for  common  data  to  a 
greater  degree  than  ever  before.  Data  falls  within 
numerous  categories  such  as  geospatial,  weather, 
imagery,  organizational,  mission  planning,  and  orders. 
A  dated  but  still  relevant  discussion  of  data  categories 
is  “Interim  Report  of  C4I-Simulation  Technical 
Reference  Model  Study  Group”,  Paper  01F-SIW-094, 
2001  Fall  Simulation  Interoperability  Workshop, 
Orlando,  FL,  September  2001.  The  common 
understanding  of  data  by  different  systems  remains  an 
issue  even  in  an  organization  like  the  military  which  is 
suppose  to  be  known  for  its  regimentation.  A  “tank” 
can  still  be  an  armored  fighting  vehicle,  a  water 
reservoir,  or  a  separate  receptacle  for  some  liquid. 
Restrictions  on  type  and  number  of  characters  in  each 
model  and  lack  of  a  standardized  naming  convention 
that  supports  all  models  continues  to  be  an  obstacle,  as 
do  multiple  standards,  formats,  and  ontology  used  by 
each  system  or  family  of  systems.  An  example  of  the 
complexity  of  this  problem  is  in  the  Army’s  effort  to 
tackle  just  the  common  data  elements  between  battle 
command  and  M&S  systems  as  part  of  the 
initialization  process.  This  subset  of  data  is  primarily 
the  force  data  (units,  soldiers,  and  equipment),  the 
units’  system  architecture,  and  the  digital  systems  and 
network  data  associated  with  that  particular  unit. 
Correlating  the  battle  command  data  bases  and  the 
supporting  M&S  data  bases  is  critical  for  proper 
stimulation  and  to  avoid  false  or  unknown  units 
displaying  on  battle  command  boxes.  Building  battle 
command  data  bases  from  scratch  today  still  takes  four 
to  five  months,  as  do  M&S  data  bases.  In  the  Army’s 
vision  to  train  and  fight  mixed  forces  (current  and 
FCS)  support  by  M&S  for  training,  course  of  action 
analysis  and  mission  rehearsal;  rapid  and  accurate  data 
initialization  is  a  critical  requirement.  Regardless  the 
Army  has  been  extremely  slow  to  recognize  and 
address  the  initialization  problem. 

4.4  Common  Standards 

Establishing  common  standards  that  can  be 
adopted  by  a  number  of  separate  programs  of  record 
all  in  different  stages  of  development  is  a  continual 
challenge.  A  good  example  is  the  JC3IEDM  standard 
initially  approved  by  the  Army  G3  in  FY05  (then 
called  the  C2IEDM).  Implementation  of  the  policy 
has  taken  over  two  years  to  date  and  in  the  mean  time 
while  some  new  systems  have  adopted  the  standard, 


others  have  not.  Current  systems  are  not  required  to 
adopt  the  JC3IEDM  internally  however  they  are 
required  to  use  it  when  exchanging  data  externally 
with  another  family  of  systems.  A  conflicting  issue  is 
that  PMs  are  similarly  encouraged  to  adopt  existing 
applications,  components,  and  services  to  save 
resources  but  these  existing  tools  may  or  may  not  use 
the  required  JC3IEDM  standard.  So  cost  savings  may, 
and  often  do,  trump  standardization.  Today  ABCS  is 
using  unique  data  standards,  a  result  from  having  been 
built  from  many  disparate  systems.  Recently  however 
ABCS  announced  it  plans  to  develop  a  Universal  Core 
data  model  which  is  not  JC3IEDM  compliant.  FCS 
has  announced  it  will  use  a  JC3IEDM  compliant  data 
model,  a  step  in  the  right  direction.  On  the  other  hand 
M&S  has  numerous  data  models  none  of  which  are 
JC3IEDM  compliant,  and  no  plan  to  move  towards  a 
single  data  standard.  As  battle  command,  FCS, 
NECC,  and  M&S  develop  and  migrate,  decisions  on 
standards  are  required  to  avoid  the  need  for  1  to  n  data 
exchange  solutions.  The  lack  of  clear  and  enforceable 
guidance  across  the  systems  will  result  in  mismatches 
and  the  continual  development  of  data  mapping  tools. 

4.5  Reusable  Component  Interfaces 

A  long  term  goal  of  the  SIMCI  OIPT  has  been  to 
encourage  common  use  of  components  between  battle 
command  systems  and  M&S  to  facilitate 
interoperability  and  reduce  costs.  In  FY00  the  SIMCI 
OIPT  funded  an  effort  by  several  simulation  interface 
developers  to  integrate  and  the  ABCS  Common 
Software’s  Common  Message  Parser  (CMP)  to  build 
and  exchange  messages  with  battle  command  systems. 
This  effort  was  a  success  and  at  least  four  interfaces 
continue  to  use  the  CMP  in  their  systems.  Despite  the 
success  of  this  project  little  other  co-use  of 
components  by  either  M&S  or  BC  has  occurred. 
Logically  movement  to  a  SO  A  should  encourage  the 
co-use  of  services  by  each  program  as  long  as  other 
issues  such  as  metadata,  data  exchange  models,  and 
security  are  also  coordinated.  However  there  are  many 
other  opportunities  where  co-use  of  products  should 
and  need  to  be  implemented.  A  single  initialization 
process  for  both  battle  command  and  M&S  accessing 
the  same  data  base  to  avoid  data  mismatches  must  be 
implemented  for  M&S  systems,  ABCS,  and  FCS. 
Both  battle  command  systems  and  M&S  systems  use 
terrain  which  must  be  correlated  between  the  two  for 
proper  stimulation  yet  there  is  no  common  terrain  or 
geospatial  development  tool.  FCS’  embedded  training 
capability  includes  after  action  review  tools  which 
must  be  able  to  collect  and  share  data  with  current  BC 
and  M&S  systems  for  mixed  force  training  exercises. 


What  is  lacking  today  is  a  comprehensive  list  of 
possible  co-use  opportunities  or  the  means  to 
implement  them. 

4.6  Technical  Challenges  Conclusion 

Ensuring  cost  effective,  interoperability  of  ABCS, 
FCS,  and  M&S  systems  as  they  migrate  will  involve 
many  more  technical  challenges  than  the  examples 
highlighted  in  this  section.  The  key  to  identifying 
those  challenges  is  use  of  a  framework  like  that 
developed  in  the  house  chart  coupled  with  an  effective 
process  that  not  only  identifies  the  challenges  but 
develops  coordinated  and  integrated  solutions. 

5.  Potential  Solutions 

The  bottom  line  of  any  solution  must  be  that  the 
organization’s  people  and  equipment  must  effectively 
interoperate.  This  is  a  requirement  that  is  focused  on 
location  and  date.  A  specific  Unit’s  equipment, 
personnel,  superior  unit,  and  subordinate  units  are  not 
standard  and  can  change  over  time.  For  example,  the 
interoperability  requirements  for  Units  in  Korea  in 
2008  can  be  different  from  the  interoperability 
requirements  for  Units  in  Iraq  in  2009.  Therefore,  any 
enterprise  wide  solution  must  take  into  consideration 
the  interoperability  requirements  caused  by  the 
deployment  of  system  versions. 

5.1  Technical  Solutions 

Since  simulations  have  to  simulate  and  stimulate 
C2  systems  they  have  the  same  interoperability 
requirements  as  a  minimum.  Technical  solutions  will 
have  to  address  interoperability  using  Bit  oriented 
messaging,  Character  oriented  messaging,  Database 
data  exchanges,  and  Service  Oriented  information 
exchanges.  The  problem  is  that  there  are  many 
standards  being  used  and  many  different  versions  of 
standards  that  change  over  time. 

5.1.1  Common  Standard 

All  C2  systems  could  quickly  migrate  to  the  same 
standard  and  to  put  in  place  a  Configuration 
Management  (CM)  and  fielding  process  to  keep 
fielded  systems  aligned. 


5.1.2  Mitigation  Server 

A  set  of  mitigation  servers  could  be  implemented 
that  would  convert  between  all  of  the  existing  and 
planned  standards. 

5.1.3  A  Standard  and  Conversion  Software 

A  standard  for  interoperability  could  be  selected 
and  then  each  system  could  implement  conversion 
software.  A  common  CM  and  fielding  process  would 
also  have  to  be  implemented. 

5.1.4  A  Standard  and  Mitigation  Servers 

A  standard  for  interoperability  could  be  selected. 
A  set  of  mitigation  servers  could  be  implemented  that 
would  convert  between  all  of  the  existing  and  planned 
standards  and  the  standard.  A  common  CM  and 
fielding  process  would  also  have  to  be  implemented. 

5.1.5  A  Standard  with  Mitigation  Servers  and 
Conversion  Software 

A  combination  of  solutions  3  and  4  above  could 
be  implemented. 

5.2  Programmatic  Solutions 

Programmatic  improvements  can  help  with  the 
improvement  of  interoperability.  However,  they  can  be 
very  difficult  to  implement. 

5.2.1  Alignment  of  Programs 

The  C2  and  M&S  programs  could  be  aligned  to 
provide  updates/changes  to  interoperability  standards 
based  interfaces  at  the  same  time. 

5.2.2  Assigning  Oversight 

An  organization  (existing  or  newly  formed)  can  be 
given  the  responsibility  and  authority  to  ensure 
interoperability  across  C2  and  M&S  systems.  It  would 
also  have  to  be  resourced. 

6.  Issues/Barriers 

Programmatic  solutions  are  very  hard  to 
implement.  Current  DoD  acquisition  processes  are 
grounded  in  the  management  of  systems.  Implementing 
cross  program/system  processes  would  conflict  with 
the  responsibility  and  authority  of  the  program/project 


managers.  In  addition,  resources  would  have  to  be 
extracted  from  the  existing  programs  in  order  to 
effectively  implement  a  cross  system/program  process. 
The  Software  Blocking  program  and  the  SIMCI 
program  are  examples  of  cross  system/program  efforts 
that  have  had  some  success.  However,  their  authority 
is  not  strong  enough  to  be  fully  effective. 

Alignment  of  programs  can  only  be  partially 
implemented  due  to  the  variables  impacting  the 
program  schedules  (e.g.  funding,  program  slips, 
technology  failures).  Interoperability  alignment  can  be 
set  up  for  timeframe  fieldings.  However  resources  and 
authority  have  to  be  included. 

The  largest  issue  with  various  technology 
alternatives  is  the  impact  on  existing 
systems/programs.  Currently  there  is  no  process 
controlling  or  aligning  technology  migration/transition 
activities.  If  this  situation  is  not  improved,  then 
technology  solutions  will  be  implemented  in  an 
uncoordinated  stovepipe  manner  which  could  result  in 
a  degradation  of  existing  interoperability. 
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Technical  Challenges 

•  Ensuring  cost  effective,  interoperability  of  ABCS, 
FCS,  and  M&S  systems  as  they  migrate  will 
involve  many  technical  challenges 

•  The  key  to  identifying  those  challenges  is  use  of 
a  framework  like  that  developed  in  the  house 
chart  coupled  with  an  effective  process  that  not 
only  identifies  the  challenges  but  develops 

coordinated  and  integrated  solutions. 

-  Processes  for  Alignment  &  Migration 

-  Alignment  of  Architectures 

-  Common  Data 

-  Common  Standards 

-  Reusable  Component  Interfaces 


Potential  Solutions 

•  An  organization’s  people  and  equipment  must 
effectively  interoperate. 

-  focused  on  location  and  date 

•  Each  specific  Unit  is  not  standard  and  can 
change  over  time. 

•  Any  enterprise  wide  solution  must  take  into 
consideration  the  interoperability  requirements 
caused  by  the  deployment  of  system  versions. 

•  Technical  Solutions 

•  Programmatic  Solutions 


Technical  Solutions 


•  Common  Standard 

-  All  C2  systems  could  quickly  migrate  to  the  same  standard  and 
to  put  in  place  a  Configuration  Management  (CM)  and  fielding 
process  to  keep  fielded  systems  aligned. 

•  Mitigation  Server 

-  A  set  of  mitigation  servers  could  be  implemented  that  would 
convert  between  all  of  the  existing  and  planned  standards. 

•  A  Standard  and  Conversion  Software 

-  A  standard  for  interoperability  could  be  selected  and  then  each 
system  could  implement  conversion  software.  A  common  CM 
and  fielding  process  would  also  have  to  be  implemented. 

•  A  Standard  and  Mitigation  Servers 

-  A  standard  for  interoperability  could  be  selected.  A  set  of 

mitigation  servers  could  be  implemented  that  would  convert 
between  all  of  the  existing  and  planned  standards  and  the 
standard.  A  common  CM  and  fielding  process  would  also  have 
to  be  implemented.  13 


Programmatic  Solutions 

•  Alignment  of  Programs 

-  The  C2  and  M&S  programs  could  be  aligned 
to  provide  updates/changes  to  interoperability 
standards  based  interfaces  at  the  same  time. 

•  Assigning  Oversight 

-An  organization  (existing  or  newly  formed) 
can  be  given  the  responsibility  and  authority 
to  ensure  interoperability  across  C2  and  M&S 
systems.  It  would  also  have  to  be  resourced. 


Issues/Barriers 

•  Programmatic  solutions  are  very  hard  to  implement 

-  Current  DoD  acquisition  processes  are  grounded  in  the 
management  of  single  systems 

-  Implementing  cross  program/system  processes  would  conflict 
with  the  responsibility  and  authority  of  the  existing 
program/project  managers 

-  Resources  would  have  to  be  extracted  from  the  existing 
programs  in  order  to  effectively  implement  a  cross 
system/program  process. 

•  Alignment  of  programs  can  only  be  partially  implemented 
due  to  the  variables  impacting  the  program  schedules 
(e.g.  funding,  program  slips,  technology  failures). 

-  Interoperability  alignment  can  be  set  up  for  timeframe  fieldings. 
However  resources  and  authority  have  to  be  included. 

•  The  largest  issue  with  various  technology  alternatives  is 
the  impact  on  existing  systems/programs. 

-  Currently  there  is  no  process  controlling  or  aligning  technology 

migration/transition  activities.  15 


